Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use collection types for return values #1447

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Use collection types for return values #1447

wants to merge 2 commits into from

Conversation

jf2048
Copy link
Member

@jf2048 jf2048 commented Mar 1, 2023

Is there a better way to get the actual type of a C array from the builder? The best I could do is adding the c_type like this.

I left the Vec<OsString> and Vec<PathBuf> return as is, since those require allocations and they are opt-in.

@jf2048 jf2048 mentioned this pull request Mar 1, 2023
Merged
This was referenced Mar 1, 2023
Merged
Merged
@sdroege
Copy link
Member

sdroege commented Mar 1, 2023

Can you make a draft PR with the changes this causes in the generated code?

@sdroege
Copy link
Member

sdroege commented Mar 2, 2023

What also might be worth considering here is parameters.

  • transfer-none array parameters can be handled directly as &[T] for many types (shared, boxed, object) as long as the C function takes a length (i.e. does not require a NULL-terminated array)
  • transfer-full collection parameters can be handled as exactly the underlying type
  • For NULL-terminated string arrays there's impl IntoStrV (transfer-none) and StrV

This might also be something to handle in a separate PR though.

@jf2048
Copy link
Member Author

jf2048 commented Mar 5, 2023

Those should be handled in #1448

This was referenced Mar 5, 2023
Draft
Closed
Draft
@sdroege
Copy link
Member

sdroege commented Mar 11, 2023

Those should be handled in #1448

The first two fit more here or in a separate PR, or not? #1448 is string stuff, this here is collections :) The third one fits better in #1448 though, that's true.

@sdroege
Copy link
Member

sdroege commented Mar 14, 2023

Looks good to me otherwise, if that wasn't clear. How should we proceed? :)

@jf2048
Copy link
Member Author

jf2048 commented Apr 30, 2023

Sorry for delay, I did some more testing and this is looking good for me too. But I think this situation should be resolved first: gtk-rs/gtk-rs-core#1078

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sdroege sdroege sdroege left review comments

@pbor pbor pbor left review comments

@bilelmoussaoui bilelmoussaoui Awaiting requested review from bilelmoussaoui

@GuillaumeGomez GuillaumeGomez Awaiting requested review from GuillaumeGomez

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@jf2048 @sdroege @pbor